1. Field of the Invention
This invention relates in general to improvements in the field of computer systems having backup/restore or archive/retrieve subsystems, and more particularly, to a method for implementing point-in-time copy operations using multiple copy technologies.
2. Description of Related Art
In a data processing system, a backup/restore subsystem is typically used to save a recent copy or version of one or more data sets or portion thereof on some form of backup data storage device, such as magnetic or optical disk drives, tape drives, or other memory.
The backup/restore subsystem is used to protect against loss of data. For example, if an on-line version of one or more data sets is destroyed, corrupted, deleted, or changed because of power failure, hardware, or software error, user error or some other type of problem, the latest version of those data sets which are stored in a backup/restore subsystem can be restored and therefore the risk of loss of data is minimized. It is readily apparent that backup/restore subsystems are and will remain an important part of the field of data processing.
Successful recovery of data to a known consistent state requires a backup of all components of the data at the same consistent point-in-time. Generally, a point-in-time backup is a copy of the data that is logically consistent to a given point-in-time, with the restriction that the amount of time to obtain logical consistency is significantly less than the amount of time to actually copy the data.
Concurrent copy, also known as time-zero copy, provides the ability to create a point-in-time backup. Concurrent copy is a point-in-time backup which uses a combination software and microcode architecture to obtain a copy of the original data at the time the backup was initiated.
Snapshot copy also provides the ability to create a point-in-time backup. In the snapshot copy, pointers are copied from a virtual track table of a source virtual volume to a virtual track table of a work virtual volume, without actually moving any data on data storage devices referenced by those pointers. Upon completion of the snapshot copy, updates to the source virtual volume may be resumed. Subsequently, a backup is performed in the usual manner, except that the backup retrieves the source data from the work virtual volume rather than the source virtual volume. As a result, the snapshot provides a method for copying the source virtual volume to the work virtual volume very quickly. (The snapshot copy is further described in the above-mentioned co-pending and commonly-assigned patent application Ser. No. 09/006,548, filed on same date herewith, by David R. Blea, Donald R. Blea, Mark A. Haye, Ronald M. Kern, David M. Shackelford, and John G. Thompson, entitled "METHOD FOR IMPLEMENTING POINT-IN-TIME COPY USING A SNAPSHOT FUNCTION," attorney's docket number TU997076, which application is incorporated herein by reference.)
Unfortunately, the concurrent copy and snapshot copy are only supported on data storage subsystems that actually implement and provide these functions. Accordingly, although concurrent copy and snapshot copy each provide the ability to create a point-in-time backup, they cannot be used if part of a desired data set resides on data storage devices that support only concurrent copy and part of a desired data set resides on data storage devices that support only snapshot copy.
A main part of this problem is data set availability. To achieve a point-in-time backup, updates to the data set must be quiesced or suspended. Concurrent copy and snapshot copy each provide a quiesce window lasting on the order of several seconds. However, when concurrent copy and snapshot copy cannot be used, quiescing updates for the duration of a backup could take many minutes to hours. Unavailability of the database for this duration is simply unacceptable for most database applications, such as those for automatic teller machines (ATMs) and airline reservations systems. Therefore, a solution is needed that provides the same minimal quiesce window as concurrent copy and snapshot copy do individually.
An additional problem occurs when a backup terminates prematurely. Currently, concurrent copy loses the consistency point if any part of the concurrent copy operation fails. This can present difficulties in environments where backup windows are rare and/or failure of backup is costly. Therefore, a restart capability is needed to overcome this problem, which presents a unique challenge if multiple backup technologies are used.
On the other hand, the snapshot copy provides the ability of being able to restart backup operations without losing the consistency point of the data base, whereas concurrent copy technology may not. This difference between the technologies provides a challenge in making the technologies transparent to an end user, while providing all the capabilities each technology allows.
Thus, there is a need in the art for improved methods for providing point-in-time backup of entire data set in which different parts of data set reside on devices supporting different copy technologies.